Odkrywanie elastycznej nawigacji po drzewach: Dogłębna analiza generycznego wzorca wizytatora

W świecie inżynierii oprogramowania często spotykamy się z danymi zorganizowanymi w hierarchiczne, drzewiaste struktury. Od abstrakcyjnych drzew składni (AST), których kompilatory używają do zrozumienia naszego kodu, przez model obiektowy dokumentu (DOM), który napędza sieć, aż po proste systemy plików – drzewa są wszędzie. Fundamentalnym zadaniem podczas pracy z tymi strukturami jest przechodzenie (trawersacja): odwiedzanie każdego węzła w celu wykonania pewnej operacji. Wyzwaniem jest jednak zrobienie tego w sposób czysty, łatwy w utrzymaniu i rozszerzalny.

Tradycyjne podejścia często osadzają logikę operacyjną bezpośrednio w klasach węzłów. Prowadzi to do monolitycznego, silnie powiązanego kodu, który narusza podstawowe zasady projektowania oprogramowania. Dodanie nowej operacji, takiej jak formatowanie kodu (pretty-printer) czy walidator, zmusza do modyfikacji każdej klasy węzła, czyniąc system kruchym i trudnym w utrzymaniu.

Klasyczny wzorzec projektowy Visitor oferuje potężne rozwiązanie, oddzielając algorytmy od obiektów, na których działają. Ale nawet klasyczny wzorzec ma swoje ograniczenia, szczególnie jeśli chodzi o rozszerzalność. To właśnie tutaj generyczny wzorzec Visitor, zwłaszcza w zastosowaniu do przechodzenia drzewa, pokazuje swoją siłę. Wykorzystując nowoczesne cechy języków programowania, takie jak typy generyczne, szablony i warianty, możemy stworzyć wysoce elastyczny, reużywalny i potężny system do przetwarzania dowolnej struktury drzewiastej.

Ta dogłębna analiza przeprowadzi Cię przez podróż od klasycznego wzorca Visitor do zaawansowanej, generycznej implementacji. Zbadamy:

• Przypomnienie klasycznego wzorca Visitor i jego nieodłącznych wyzwań.
• Ewolucję w kierunku podejścia generycznego, które jeszcze bardziej oddziela operacje.
• Szczegółową, krok po kroku implementację generycznego wizytatora do przechodzenia drzewa.
• Głębokie korzyści płynące z oddzielenia logiki przechodzenia od logiki operacyjnej.
• Praktyczne zastosowania, w których ten wzorzec dostarcza ogromną wartość.

Niezależnie od tego, czy budujesz kompilator, narzędzie do analizy statycznej, framework UI, czy jakikolwiek system oparty na złożonych strukturach danych, opanowanie tego wzorca podniesie Twoje myślenie architektoniczne i jakość Twojego kodu.

Powrót do klasycznego wzorca Visitor

Zanim docenimy ewolucję generyczną, musimy solidnie zrozumieć jej fundament. Wzorzec Visitor, opisany przez "Bandę Czworga" w ich przełomowej książce Wzorce projektowe: Elementy oprogramowania obiektowego wielokrotnego użytku, to wzorzec behawioralny, który pozwala dodawać nowe operacje do istniejących struktur obiektów bez modyfikowania tych struktur.

Problem, który rozwiązuje

Wyobraź sobie, że masz proste drzewo wyrażeń arytmetycznych złożone z różnych typów węzłów, takich jak NumberNode (wartość literalna) i AdditionNode (reprezentujący dodawanie dwóch podwyrażeń). Możesz chcieć wykonać kilka odrębnych operacji na tym drzewie:

• Ewaluacja: Obliczenie ostatecznego wyniku numerycznego wyrażenia.
• Formatowanie (Pretty Printing): Wygenerowanie czytelnej dla człowieka reprezentacji tekstowej, np. "(5 + 3)".
• Sprawdzanie typów: Weryfikacja, czy operacje są prawidłowe dla zaangażowanych typów.

Naiwne podejście polegałoby na dodaniu metod takich jak `evaluate()`, `print()` i `typeCheck()` do bazowej klasy `Node` i nadpisaniu ich w każdej konkretnej klasie węzła. To zaśmieca klasy węzłów niepowiązaną logiką. Za każdym razem, gdy wymyślisz nową operację, musisz dotknąć każdej pojedynczej klasy węzła w hierarchii. Narusza to zasadę otwarte-zamknięte, która mówi, że byty oprogramowania powinny być otwarte na rozszerzenia, ale zamknięte na modyfikacje.

Klasyczne rozwiązanie: Podwójne wywołanie (Double Dispatch)

Wzorzec Visitor rozwiązuje ten problem, wprowadzając dwie nowe hierarchie: hierarchię Visitor i hierarchię Element (nasze węzły). Magia tkwi w technice zwanej podwójnym wywołaniem (double dispatch).

Kluczowi gracze to:

• Interfejs Elementu (np. `Node`): Definiuje metodę `accept(Visitor v)`.
• Konkretne Elementy (np. `NumberNode`, `AdditionNode`): Implementują metodę `accept`. Implementacja jest prosta: `visitor.visit(this);`.
• Interfejs Visitora: Deklaruje przeciążoną metodę `visit` dla każdego konkretnego typu elementu. Na przykład `visit(NumberNode n)` i `visit(AdditionNode n)`.
• Konkretny Visitor (np. `EvaluationVisitor`, `PrintVisitor`): Implementuje metody `visit` w celu wykonania określonej operacji.

Oto jak to działa: Wywołujesz `node.accept(myVisitor)`. Wewnątrz `accept`, węzeł wywołuje `myVisitor.visit(this)`. W tym momencie kompilator zna konkretny typ `this` (np. `AdditionNode`) i konkretny typ `myVisitor` (np. `EvaluationVisitor`). Może zatem wywołać właściwą metodę `visit`: `EvaluationVisitor::visit(AdditionNode*)`. To dwuetapowe wywołanie osiąga to, czego pojedyncze wywołanie funkcji wirtualnej nie może: rozwiązanie właściwej metody na podstawie typów wykonawczych dwóch różnych obiektów.

Ograniczenia klasycznego wzorca

Choć elegancki, klasyczny wzorzec Visitor ma istotną wadę, która utrudnia jego stosowanie w ewoluujących systemach: sztywność w hierarchii elementów.

Interfejs `Visitor` zawiera metodę `visit` dla każdego typu `ConcreteElement`. Jeśli chcesz dodać nowy typ węzła — powiedzmy, `MultiplicationNode` — musisz dodać nową metodę `visit(MultiplicationNode n)` do bazowego interfejsu `Visitor`. To zmusza do aktualizacji każdej pojedynczej konkretnej klasy wizytatora istniejącej w systemie, aby zaimplementowała tę nową metodę. Ten sam problem, który rozwiązaliśmy dla dodawania nowych operacji, pojawia się teraz przy dodawaniu nowych typów elementów. System jest zamknięty na modyfikacje po stronie operacji, ale szeroko otwarty po stronie elementów.

Ta cykliczna zależność między hierarchią elementów a hierarchią wizytatorów jest główną motywacją do poszukiwania bardziej elastycznego, generycznego rozwiązania.

Ewolucja generyczna: Bardziej elastyczne podejście

Głównym ograniczeniem klasycznego wzorca jest statyczne, kompilacyjne powiązanie między interfejsem wizytatora a konkretnymi typami elementów. Podejście generyczne dąży do zerwania tego powiązania. Centralną ideą jest przeniesienie odpowiedzialności za wywołanie właściwej logiki obsługi z sztywnego interfejsu przeciążonych metod.

Nowoczesny C++, z jego potężnym metaprogramowaniem szablonowym i funkcjami biblioteki standardowej, takimi jak `std::variant`, zapewnia wyjątkowo czysty i wydajny sposób na implementację tego. Podobne podejście można osiągnąć w językach takich jak C# czy Java, używając refleksji lub interfejsów generycznych, aczkolwiek z potencjalnymi kompromisami wydajnościowymi.

Naszym celem jest zbudowanie systemu, w którym:

1. Dodawanie nowych typów węzłów jest zlokalizowane i nie wymaga kaskady zmian we wszystkich istniejących implementacjach wizytatorów.
2. Dodawanie nowych operacji pozostaje proste, zgodnie z pierwotnym celem wzorca Visitor.
3. Sama logika przechodzenia (np. pre-order, post-order) może być zdefiniowana generycznie i ponownie wykorzystana dla dowolnej operacji.

Ten trzeci punkt jest kluczem do naszej "Implementacji typu przechodzenia drzewa". Nie tylko oddzielimy operację od struktury danych, ale także oddzielimy akt przechodzenia od aktu operowania.

Implementacja generycznego wizytatora do przechodzenia drzewa w C++

Użyjemy nowoczesnego C++ (C++17 lub nowszego), aby zbudować nasz generyczny framework wizytatora. Połączenie `std::variant`, `std::unique_ptr` i szablonów daje nam bezpieczne typowo, wydajne i wysoce ekspresyjne rozwiązanie.

Krok 1: Definiowanie struktury węzła drzewa

Najpierw zdefiniujmy nasze typy węzłów. Zamiast tradycyjnej hierarchii dziedziczenia z wirtualną metodą `accept`, zdefiniujemy nasze węzły jako proste struktury. Następnie użyjemy `std::variant`, aby utworzyć typ sumy, który może przechowywać dowolny z naszych typów węzłów.

Aby umożliwić rekurencyjną strukturę (drzewo, w którym węzły zawierają inne węzły), potrzebujemy warstwy pośredniej. Struktura `Node` będzie opakowywać wariant i używać `std::unique_ptr` dla swoich dzieci.

Plik: `Nodes.h`

#include <memory> #include <variant> #include <vector> // Deklaracja wyprzedzająca głównego wrappera Node struct Node; // Definicja konkretnych typów węzłów jako prostych agregatów danych struct NumberNode {     double value; }; struct BinaryOpNode {     enum class Operator { Add, Subtract, Multiply, Divide };     Operator op;     std::unique_ptr<Node> left;     std::unique_ptr<Node> right; }; struct UnaryOpNode {     enum class Operator { Negate };     Operator op;     std::unique_ptr<Node> operand; }; // Użycie std::variant do stworzenia typu sumy wszystkich możliwych typów węzłów using NodeVariant = std::variant<NumberNode, BinaryOpNode, UnaryOpNode>; // Główna struktura Node, która opakowuje wariant struct Node {     NodeVariant var; };

Ta struktura to już ogromne ulepszenie. Typy węzłów to zwykłe struktury danych (plain old data structs). Nie mają wiedzy o wizytatorach ani żadnych operacjach. Aby dodać `FunctionCallNode`, wystarczy zdefiniować strukturę i dodać ją do aliasu `NodeVariant`. Jest to pojedynczy punkt modyfikacji dla samej struktury danych.

Krok 2: Tworzenie generycznego wizytatora z `std::visit`

Narzędzie `std::visit` jest kamieniem węgielnym tego wzorca. Przyjmuje obiekt wywoływalny (taki jak funkcja, lambda lub obiekt z `operator()`) oraz `std::variant` i wywołuje odpowiednie przeciążenie obiektu wywoływalnego na podstawie typu aktualnie aktywnego w wariancie. To jest nasz bezpieczny typowo, kompilacyjny mechanizm podwójnego wywołania.

Wizytator to teraz po prostu struktura z przeciążonym `operator()` dla każdego typu w wariancie.

Stwórzmy prosty wizytator Pretty-Printer, aby zobaczyć to w akcji.

Plik: `PrettyPrinter.h`

#include "Nodes.h" #include <string> #include <iostream> struct PrettyPrinter {     // Przeciążenie dla NumberNode     void operator()(const NumberNode& node) const {         std::cout << node.value;     }     // Przeciążenie dla UnaryOpNode     void operator()(const UnaryOpNode& node) const {         std::cout << "(-";         std::visit(*this, node.operand->var); // Rekurencyjne odwiedzenie         std::cout << ")";     }     // Przeciążenie dla BinaryOpNode     void operator()(const BinaryOpNode& node) const {         std::cout << "(";         std::visit(*this, node.left->var); // Rekurencyjne odwiedzenie         switch (node.op) {             case BinaryOpNode::Operator::Add: std::cout << " + "; break;             case BinaryOpNode::Operator::Subtract: std::cout << " - "; break;             case BinaryOpNode::Operator::Multiply: std::cout << " * "; break;             case BinaryOpNode::Operator::Divide: std::cout << " / "; break;         }         std::visit(*this, node.right->var); // Rekurencyjne odwiedzenie         std::cout << ")";     } };

Zauważ, co się tutaj dzieje. Logika przechodzenia (odwiedzanie dzieci) i logika operacyjna (drukowanie nawiasów i operatorów) są wymieszane wewnątrz `PrettyPrinter`. To działa, ale możemy zrobić to jeszcze lepiej. Możemy oddzielić co od jak.

Krok 3: Gwiazda programu - Generyczny wizytator do przechodzenia drzewa

Teraz wprowadzamy kluczową koncepcję: reużywalny `TreeWalker`, który hermetyzuje strategię przechodzenia. Ten `TreeWalker` sam będzie wizytatorem, ale jego jedynym zadaniem jest przechodzenie po drzewie. Będzie przyjmował inne funkcje (lambdy lub obiekty funkcyjne), które są wykonywane w określonych punktach podczas przechodzenia.

Możemy wspierać różne strategie, ale popularną i potężną jest dostarczenie haków (hooks) dla "pre-visit" (przed odwiedzeniem dzieci) i "post-visit" (po odwiedzeniu dzieci). Odpowiada to bezpośrednio akcjom przechodzenia w porządku pre-order i post-order.

Plik: `TreeWalker.h`

#include "Nodes.h" #include <functional> template <typename PreVisitAction, typename PostVisitAction> struct TreeWalker {     PreVisitAction pre_visit;     PostVisitAction post_visit;     // Przypadek bazowy dla węzłów bez dzieci (terminali)     void operator()(const NumberNode& node) {         pre_visit(node);         post_visit(node);     }     // Przypadek dla węzłów z jednym dzieckiem     void operator()(const UnaryOpNode& node) {         pre_visit(node);         std::visit(*this, node.operand->var); // Rekurencja         post_visit(node);     }     // Przypadek dla węzłów z dwójką dzieci     void operator()(const BinaryOpNode& node) {         pre_visit(node);         std::visit(*this, node.left->var); // Rekurencja w lewo         std::visit(*this, node.right->var); // Rekurencja w prawo         post_visit(node);     } }; // Funkcja pomocnicza ułatwiająca tworzenie walkera template <typename Pre, typename Post> auto make_tree_walker(Pre pre, Post post) {     return TreeWalker<Pre, Post>{pre, post}; }

Ten `TreeWalker` to arcydzieło separacji. Nie wie nic o drukowaniu, ewaluacji czy sprawdzaniu typów. Jego jedynym celem jest wykonanie przechodzenia w głąb drzewa i wywołanie dostarczonych haków. Akcja `pre_visit` jest wykonywana w porządku pre-order, a akcja `post_visit` w porządku post-order. Wybierając, którą lambdę zaimplementować, użytkownik może wykonać dowolny rodzaj operacji.

Krok 4: Używanie `TreeWalker` do potężnych, odseparowanych operacji

Teraz zrefaktoryzujmy nasz `PrettyPrinter` i stwórzmy `EvaluationVisitor` używając naszego nowego, generycznego `TreeWalker`. Logika operacyjna będzie teraz wyrażona jako proste lambdy.

Aby przekazywać stan między wywołaniami lambd (jak stos ewaluacji), możemy przechwytywać zmienne przez referencję.

Plik: `main.cpp`

#include "Nodes.h" #include "TreeWalker.h" #include <iostream> #include <string> #include <vector> // Pomocnik do tworzenia generycznej lambdy, która obsłuży każdy typ węzła template<class... Ts> struct Overloaded : Ts... { using Ts::operator()...; }; template<class... Ts> Overloaded(Ts...) -> Overloaded<Ts...>; int main() {     // Zbudujmy drzewo dla wyrażenia: (5 + (10 * 2))     auto num5 = std::make_unique<Node>(Node{NumberNode{5.0}});     auto num10 = std::make_unique<Node>(Node{NumberNode{10.0}});     auto num2 = std::make_unique<Node>(Node{NumberNode{2.0}});     auto mult = std::make_unique<Node>(Node{BinaryOpNode{         BinaryOpNode::Operator::Multiply, std::move(num10), std::move(num2)     }});     auto root = std::make_unique<Node>(Node{BinaryOpNode{         BinaryOpNode::Operator::Add, std::move(num5), std::move(mult)     }});     std::cout << "--- Pretty Printing Operation ---\n";     auto printer_pre_visit = Overloaded {         [](const NumberNode& node) { std::cout << node.value; },         [](const UnaryOpNode&) { std::cout << "(-"; },         [](const BinaryOpNode&) { std::cout << "("; }     };     auto printer_post_visit = Overloaded {         [](const NumberNode&) {}, // Do nothing         [](const UnaryOpNode&) { std::cout << ")"; },         [](const BinaryOpNode& node) {             switch (node.op) {                 case BinaryOpNode::Operator::Add: std::cout << " + "; break;                 case BinaryOpNode::Operator::Subtract: std::cout << " - "; break;                 case BinaryOpNode::Operator::Multiply: std::cout << " * "; break;                 case BinaryOpNode::Operator::Divide: std::cout << " / "; break;             }         }     }; // To nie zadziała, ponieważ dzieci są odwiedzane pomiędzy pre i post. // Udoskonalmy walker, aby był bardziej elastyczny dla drukowania in-order. // Lepszym podejściem do formatowania jest posiadanie haka "in-visit". // Dla uproszczenia, zmieńmy nieco strukturę logiki drukowania. // Albo lepiej, stwórzmy dedykowany PrintWalker. Na razie trzymajmy się pre/post i pokażmy ewaluację, która lepiej pasuje.     std::cout << "\n--- Evaluation Operation ---\n";     std::vector<double> eval_stack;     auto eval_pre_visit = [](const auto&){}; // Nic nie rób przy pre-visit     auto eval_post_visit = Overloaded {         [&](const NumberNode& node) {             eval_stack.push_back(node.value);         },         [&](const UnaryOpNode& node) {             double operand = eval_stack.back(); eval_stack.pop_back();             eval_stack.push_back(-operand);         },         [&](const BinaryOpNode& node) {             double right = eval_stack.back(); eval_stack.pop_back();             double left = eval_stack.back(); eval_stack.pop_back();             switch(node.op) {                 case BinaryOpNode::Operator::Add: eval_stack.push_back(left + right); break;                 case BinaryOpNode::Operator::Subtract: eval_stack.push_back(left - right); break;                 case BinaryOpNode::Operator::Multiply: eval_stack.push_back(left * right); break;                 case BinaryOpNode::Operator::Divide: eval_stack.push_back(left / right); break;             }         }     };     auto evaluator = make_tree_walker(eval_pre_visit, eval_post_visit);     std::visit(evaluator, root->var);     std::cout << "Evaluation result: " << eval_stack.back() << std::endl;     return 0; }

Spójrz na logikę ewaluacji. Idealnie pasuje do przechodzenia post-order. Wykonujemy operację dopiero po obliczeniu wartości jej dzieci i umieszczeniu ich na stosie. Lambda `eval_post_visit` przechwytuje `eval_stack` i zawiera całą logikę ewaluacji. Ta logika jest całkowicie oddzielona od definicji węzłów i `TreeWalker`. Osiągnęliśmy piękną, trójstronną separację odpowiedzialności: struktura danych (Węzły), algorytm przechodzenia (`TreeWalker`) i logika operacji (lambdy).

Korzyści z podejścia generycznego wizytatora

Ta strategia implementacji przynosi znaczne korzyści, zwłaszcza w dużych, długo żyjących projektach oprogramowania.

Niezrównana elastyczność i rozszerzalność

To jest główna korzyść. Dodanie nowej operacji jest trywialne. Po prostu piszesz nowy zestaw lambd i przekazujesz je do `TreeWalker`. Nie dotykasz żadnego istniejącego kodu. To doskonale przestrzega zasady otwarte-zamknięte. Dodanie nowego typu węzła wymaga dodania struktury i zaktualizowania aliasu `std::variant` — pojedyncza, zlokalizowana zmiana — a następnie zaktualizowania wizytatorów, które muszą go obsłużyć. Kompilator pomocnie poinformuje Cię, którym dokładnie wizytatorom (przeciążonym lambdom) brakuje teraz przeciążenia.

Doskonała separacja odpowiedzialności

Wyizolowaliśmy trzy odrębne odpowiedzialności:

• Reprezentacja danych: Struktury `Node` to proste, bierne kontenery danych.
• Mechanika przechodzenia: Klasa `TreeWalker` wyłącznie posiada logikę nawigacji po strukturze drzewa. Można łatwo stworzyć `InOrderTreeWalker` lub `BreadthFirstTreeWalker` bez zmiany żadnej innej części systemu.
• Logika operacyjna: Lambdy przekazywane do walkera zawierają specyficzną logikę biznesową dla danego zadania (ewaluacja, drukowanie, sprawdzanie typów itp.).

Ta separacja sprawia, że kod jest łatwiejszy do zrozumienia, testowania i utrzymania. Każdy komponent ma jedną, dobrze zdefiniowaną odpowiedzialność.

Zwiększona reużywalność

The `TreeWalker` jest nieskończenie reużywalny. Logika przechodzenia jest napisana raz i może być zastosowana do nieograniczonej liczby operacji. Zmniejsza to duplikację kodu i potencjalne błędy, które mogą wynikać z ponownego implementowania logiki przechodzenia w każdym nowym wizytatorze.

Zwięzły i ekspresyjny kod

Dzięki nowoczesnym funkcjom C++, wynikowy kod jest często bardziej zwięzły niż klasyczne implementacje wzorca Visitor. Lambdy pozwalają na definiowanie logiki operacyjnej dokładnie tam, gdzie jest używana, co może poprawić czytelność prostych, zlokalizowanych operacji. Pomocnicza struktura `Overloaded` do tworzenia wizytatorów z zestawu lambd to powszechny i potężny idiom, który utrzymuje definicje wizytatorów w czystości.

Potencjalne kompromisy i uwagi

Żaden wzorzec nie jest panaceum. Ważne jest, aby zrozumieć związane z nim kompromisy.

Początkowa złożoność konfiguracji

Początkowa konfiguracja struktury `Node` z `std::variant` i generycznym `TreeWalker` może wydawać się bardziej złożona niż proste rekurencyjne wywołanie funkcji. Ten wzorzec przynosi najwięcej korzyści w systemach, gdzie struktura drzewa jest stabilna, ale oczekuje się, że liczba operacji będzie rosła z czasem. Dla bardzo prostych, jednorazowych zadań przetwarzania drzewa, może to być przesada.

Wydajność

Wydajność tego wzorca w C++ przy użyciu `std::visit` jest doskonała. `std::visit` jest zazwyczaj implementowane przez kompilatory przy użyciu wysoce zoptymalizowanej tablicy skoków, co sprawia, że wywołanie jest niezwykle szybkie — często szybsze niż wywołania funkcji wirtualnych. W innych językach, które mogą polegać na refleksji lub wyszukiwaniu typów w słownikach, aby osiągnąć podobne zachowanie generyczne, może wystąpić zauważalny narzut wydajnościowy w porównaniu z klasycznym, statycznie wywoływanym wizytatorem.

Zależność od języka

Elegancja i wydajność tej konkretnej implementacji są silnie zależne od funkcji C++17. Chociaż zasady są przenoszalne, szczegóły implementacji w innych językach będą się różnić. Na przykład w Javie można by użyć zapieczętowanego interfejsu i dopasowywania wzorców w nowoczesnych wersjach, lub bardziej rozwlekłego dyspozytora opartego na mapach w starszych wersjach.

Zastosowania i przypadki użycia w świecie rzeczywistym

Generyczny wzorzec Visitor do przechodzenia drzewa to nie tylko ćwiczenie akademickie; to kręgosłup wielu złożonych systemów oprogramowania.

• Kompilatory i interpretery: To kanoniczny przypadek użycia. Abstrakcyjne Drzewo Składni (AST) jest przechodzone wielokrotnie przez różne "wizytatory" lub "przebiegi". Przebieg analizy semantycznej sprawdza błędy typów, przebieg optymalizacji przepisuje drzewo, aby było bardziej wydajne, a przebieg generowania kodu przechodzi ostateczne drzewo, aby wyemitować kod maszynowy lub bajtowy. Każdy przebieg to odrębna operacja na tej samej strukturze danych.
• Narzędzia do analizy statycznej: Narzędzia takie jak lintery, formatery kodu i skanery bezpieczeństwa parsują kod do AST, a następnie uruchamiają na nim różne wizytatory, aby znaleźć wzorce, egzekwować reguły stylu lub wykrywać potencjalne luki w zabezpieczeniach.
• Przetwarzanie dokumentów (DOM): Kiedy manipulujesz dokumentem XML lub HTML, pracujesz z drzewem. Generyczny wizytator może być użyty do wyodrębnienia wszystkich linków, przekształcenia wszystkich obrazów lub serializacji dokumentu do innego formatu.
• Frameworki UI: Nowoczesne frameworki UI reprezentują interfejs użytkownika jako drzewo komponentów. Przechodzenie tego drzewa jest konieczne do renderowania, propagowania aktualizacji stanu (jak w algorytmie uzgadniania Reacta) lub wysyłania zdarzeń.
• Grafy sceny w grafice 3D: Scena 3D jest często reprezentowana jako hierarchia obiektów. Przechodzenie jest potrzebne do stosowania transformacji, przeprowadzania symulacji fizycznych i przesyłania obiektów do potoku renderującego. Generyczny walker mógłby zastosować operację renderowania, a następnie zostać ponownie użyty do zastosowania operacji aktualizacji fizyki.

Podsumowanie: Nowy poziom abstrakcji

Generyczny wzorzec Visitor, szczególnie gdy jest zaimplementowany z dedykowanym `TreeWalker`, reprezentuje potężną ewolucję w projektowaniu oprogramowania. Bierze pierwotną obietnicę wzorca Visitor — separację danych i operacji — i podnosi ją na wyższy poziom, oddzielając również złożoną logikę przechodzenia.

Dzieląc problem na trzy odrębne, ortogonalne komponenty — dane, przechodzenie i operacje — budujemy systemy, które są bardziej modułowe, łatwiejsze w utrzymaniu i solidniejsze. Zdolność do dodawania nowych operacji bez modyfikowania podstawowych struktur danych lub kodu przechodzenia jest monumentalnym zwycięstwem dla architektury oprogramowania. `TreeWalker` staje się zasobem wielokrotnego użytku, który może napędzać dziesiątki funkcji, zapewniając, że logika przechodzenia jest spójna i poprawna wszędzie tam, gdzie jest używana.

Chociaż wymaga to początkowej inwestycji w zrozumienie i konfigurację, generyczny wzorzec wizytatora do przechodzenia drzewa zwraca się z nawiązką przez cały cykl życia projektu. Dla każdego programisty pracującego ze złożonymi danymi hierarchicznymi jest to niezbędne narzędzie do pisania czystego, elastycznego i trwałego kodu.